NTISthis.com

Evidence Guide: ICASAS505A - Review and update disaster recovery and contingency plans

Student: __________________________________________________

Signature: _________________________________________________

Tips for gathering evidence to demonstrate your skills

The important thing to remember when gathering evidence is that the more evidence the better - that is, the more evidence you gather to demonstrate your skills, the more confident an assessor can be that you have learned the skills not just at one point in time, but are continuing to apply and develop those skills (as opposed to just learning for the test!). Furthermore, one piece of evidence that you collect will not usualy demonstrate all the required criteria for a unit of competency, whereas multiple overlapping pieces of evidence will usually do the trick!

From the Wiki University

 

ICASAS505A - Review and update disaster recovery and contingency plans

What evidence can you provide to prove your understanding of each of the following citeria?

Evaluate impact of system on business continuity

  1. Identify business critical functions and the security environment from documentation and from discussion with business area and project team
  2. Identify critical data and software from documentation
  3. Assess potential impact of business risk and threats on IT systems
  4. Identify and evaluate statutory requirements, commercial requirements and contingency possibilities according to specifications and cost constraints
Identify business critical functions and the security environment from documentation and from discussion with business area and project team

Completed
Date:

Teacher:		 Evidence:

 

 

 

 

 

 

 

Identify critical data and software from documentation

Completed
Date:

Teacher:		 Evidence:

 

 

 

 

 

 

 

Assess potential impact of business risk and threats on IT systems

Completed
Date:

Teacher:		 Evidence:

 

 

 

 

 

 

 

Identify and evaluate statutory requirements, commercial requirements and contingency possibilities according to specifications and cost constraints

Completed
Date:

Teacher:		 Evidence:

 

 

 

 

 

 

 

Evaluate threats to system

  1. Identify threats to the system, considering security analysis and internal and external business environment
  2. Evaluate risk minimisation alternatives against specifications and cost constraints
Identify threats to the system, considering security analysis and internal and external business environment

Completed
Date:

Teacher:		 Evidence:

 

 

 

 

 

 

 

Evaluate risk minimisation alternatives against specifications and cost constraints

Completed
Date:

Teacher:		 Evidence:

 

 

 

 

 

 

 

Formulate prevention and recovery strategy

  1. Evaluate prevention and recovery options to support critical business functions against business specifications and cost constraints
  2. Review current operational procedures to ensure that adequate risk safeguards and contingency plans are in place
  3. Submit disaster recovery and prevention strategy to appropriate person for approval
Evaluate prevention and recovery options to support critical business functions against business specifications and cost constraints

Completed
Date:

Teacher:		 Evidence:

 

 

 

 

 

 

 

Review current operational procedures to ensure that adequate risk safeguards and contingency plans are in place

Completed
Date:

Teacher:		 Evidence:

 

 

 

 

 

 

 

Submit disaster recovery and prevention strategy to appropriate person for approval

Completed
Date:

Teacher:		 Evidence:

 

 

 

 

 

 

 

Develop disaster recovery plan to support strategy

  1. Identify and document resources required for disaster recovery according to specifications and cost constraints
  2. Identify and document processes required for disaster strategy according to project standards
  3. Identify cut-over criteria before initiating disaster plan
  4. Document disaster recovery plan and submit to appropriate person for review and sign-off
Identify and document resources required for disaster recovery according to specifications and cost constraints

Completed
Date:

Teacher:		 Evidence:

 

 

 

 

 

 

 

Identify and document processes required for disaster strategy according to project standards

Completed
Date:

Teacher:		 Evidence:

 

 

 

 

 

 

 

Identify cut-over criteria before initiating disaster plan

Completed
Date:

Teacher:		 Evidence:

 

 

 

 

 

 

 

Document disaster recovery plan and submit to appropriate person for review and sign-off

Completed
Date:

Teacher:		 Evidence:

 

 

 

 

 

 

 

Assessed

Teacher: ___________________________________ Date: _________

Signature: ________________________________________________

Comments:

 

 

 

 

 

 

 

 

Instructions to Assessors

Evidence Guide

The evidence guide provides advice on assessment and must be read in conjunction with the performance criteria, required skills and knowledge, range statement and the Assessment Guidelines for the Training Package.

Overview of assessment

Critical aspects for assessment and evidence required to demonstrate competency in this unit

Evidence of the ability to:

specify contingencies that minimise down time for business critical functions

clearly specify directions on how to handle serious down time

coordinate, plan and articulate flexible logistics requirements.

Context of and specific resources for assessment

Assessment must ensure access to:

appropriate learning and assessment support when required

modified equipment for people with special needs

vulnerability assessment and general definition of requirements

acceptance test plan

business impact analysis

information technology security assurance specifications

relevant statutory documentation.

Method of assessment

A range of assessment methods should be used to assess practical skills and knowledge. The following examples are appropriate for this unit:

verbal or written questioning to assess candidate’s knowledge of the disaster recovery or contingency plan to ensure the following is covered:

defined recovery requirements from the perspective of business functions

impact of an extended loss on operations and key business functions

contingency plan is understandable, and easy to use and maintain

contingency planning considerations may be integrated into ongoing business planning and system development processes

disaster recovery plan is not a one-off activity, but rather an ongoing process

review of disaster recovery plan developed by the candidate.

Guidance information for assessment

Holistic assessment with other units relevant to the industry sector, workplace and job role is recommended, where appropriate.

Assessment processes and techniques must be culturally appropriate, and suitable to the communication skill level, language, literacy and numeracy capacity of the candidate and the work being performed.

Indigenous people and other people from a non-English speaking background may need additional support.

In cases where practical assessment is used it should be combined with targeted questioning to assess required knowledge.

Required Skills and Knowledge

Required skills

communication skills to:

gain consensus on concepts when disaster recovery plan is submitted to higher authorities for review and sign-off

negotiate with client business area and project team when business critical functions are identified from project documentation

literacy skills to interpret statutory requirements

planning and organisational skills to:

manage logistics for resources and procedures required for disaster recovery

scope project, and plan time, cost, and quality

scope communications, risk analysis and management

research skills to:

follow best practice in system development

specify, analyse and evaluate broad features of a particular business domain.

Required knowledge

backup methodologies

business planning process relevant to the development of IT business solutions

client business domain

disaster recovery plan strategies and components, including:

physical security

system failure, accident or sabotage (hackers)

denial of service

virus attack

cyber attack

telecommunications failure

OHS

legislative and organisational requirements

system's current functionality

systems engineering.

Range Statement

The range statement relates to the unit of competency as a whole. It allows for different work environments and situations that may affect performance. Bold italicised wording, if used in the performance criteria, is detailed below. Essential operating conditions that may be present with training and assessment (depending on the work situation, needs of the candidate, accessibility of the item, and local industry and regional contexts) may also be included.

Business critical functions may include:

customer service functions

financial systems

payroll.

Documentation may relate to:

audit trails

client training

International Organization for Standardization (ISO), International Electrotechnical Commission (IEC) and Australian Standards (AS) standards

maintaining equipment inventory

naming standards

project management templates and report writing

satisfaction reports

version control.

Project team may include:

different businesses working in partnership

individual business analysts

solution developers and business clients working together

third-party solution developers working together.

Software may include:

commercial

in-house

packaged or customised software.

Threats may include:

accident

cyber attack

denial of service

espionage

information technology failure

sabotage

security

telecommunications network failure

virus attack

weather, such as storms and earthquake.

Systems may include:

application service provider

applications

databases

gateways

internet service provider (ISP)

operating systems

servers.

Statutory requirements may include:

industry imposed controls and standards

legislation, such as Privacy Act

laws regarding confidentiality and reporting of data in organisations, such as health and banking.

Commercial requirements may include:

access to internal network

availability

backup

confidentiality

encryption

firewalls

hacking

integrity

passwords and logons

storage and data recovery.

Constraints may include:

budget

hardware

legal constraints

policy

resource

software

time.

Specifications may include:

current system functionality

technical requirements

user-problem statement.

Contingency plans will typically:

identify weaknesses and provide for the implementation of a disaster prevention program

minimise disruption to business operations

provide a coordinated approach to the disaster recovery process

vary in format and content detail.

Appropriate person may include:

authorised business representative

client

supervisor.

Standards may include:

ISO, IEC and AS standards

organisational standards

project standards.

Cut-over criteria may include:

actual system down time

authorisations to cut-over

estimate of business impact, including

time before system is operational

cut-over plan refresher.